…SNP to GCP TDX) (#68)

* test(tpm): validate the TPM verifier against a real Azure vTPM quote

Captured a genuine TPM 2.0 quote from an Azure Trusted Launch VM (vTPM, secure
boot, PCRs 0-7 under a fresh nonce). The verifier's parse, magic and type
checks, qualifying-data binding, PCR digest and AK RSA PKCS#1 v1.5 SHA-256
signature all hold on it, and a flipped bit in the attest blob is rejected.
Env-gated on CA2A_TPM_FIXTURE_DIR; the capture is not committed.

What this does not close, stated in docs/hardware-validation.md rather than
glossed: the AK certificate chain. Azure's pre-provisioned AK certificate
certifies a different key than an in-guest tpm2_createak AK, so it does not
verify against this quote, and it carries no AIA extension, so its issuing
intermediate is not fetchable from it. Chain-to-vendor-root stays unexercised
for TPM, which is why this verifier takes caller-supplied roots rather than
pinning one. This is also a Hyper-V vTPM, not a discrete TPM chip.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs: the attestation seam ran off a real SEV-SNP quote; assurance=hardware

Drove ca2a_runtime.attestation's verifier seam off a live SEV-SNP quote on an
Azure DC2ads_v5 confidential VM. verify_offer returned assurance="hardware"
rather than "none" for the first time, a payload was sealed to a channel key a
hardware-verified measurement vouches for and opened inside the enclave, and
both a measurement mismatch and a stale nonce were rejected.

Azure SEV-SNP is paravisor-mediated, so the binding is one hop longer than
bare-metal: the caller's nonce rides in the AK-signed TPM quote, the paravisor
binds that AK into the SNP report's REPORT_DATA, and the report chains VCEK to
ASK to ARK-Milan against AMD KDS. docs/hardware-validation.md spells that out.

What this does not close is said in the same breath, in LIMITATIONS and the
ROADMAP: the run had one attested peer with the caller on the same host, so cA2A
is still not demonstrated attested across trust domains. That needs two
independently operated attested peers. Software mode also remains the default
for the reference transport; the hardware path is a validated capability, not
the shipped default.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs: record the cross-operator, cross-TEE run (Azure SNP to GCP TDX)

An AMD SEV-SNP peer on Azure called an Intel TDX peer on GCP: different clouds,
different operators, unrelated attestation formats. The caller appraised the
callee's genuine 8KB TDX quote against the pinned Intel SGX Root CA, confirmed
the quote's REPORTDATA bound the callee's channel key under a nonce the caller
chose, and only then sealed a delegated task. The TDX enclave opened it, enforced
a scope narrowed by a chain it did not issue, allowed tool:search, and refused
tool:purchase with a denial record carrying the requested capability, the
effective scope and the reason back across the trust boundary. A stale nonce was
rejected.

That is the four primitives holding at once across a real trust boundary, which
is what the cross-operator claim rested on.

Two honest limits are recorded with it: the attestation was one-directional, so
the callee never appraised the caller, and both peers ran from one operator's
harness. Mutual simultaneous attestation is the remaining step. The committed
cross-operator example stays software-attested, because real evidence embeds
per-CPU identifiers and cannot be shipped as a fixture.

Also carries the two commits orphaned when #61 merged: the real Azure vTPM quote
test and the assurance="hardware" live-peer run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>